I'm attempting to enable a schema where I can lock attributes within an object as needed. For example, I have two attributes: stage 1, stage 2. On some objects I need to have stage 1, or stage 2, or both be un-editable (locked). The text below indicates said flexibility with, "locked" = un-editable and "open" = editable. ID --> stage1 --> stage2 1 --> open --> locked 2 --> locked --> open 3 --> locked --> locked 4 --> open --> open
Attribute Setup: attrName --> attr-def --> attr-vaule stage1 --> stage1 RMCD --> stage1 RMCD stage2 --> stage2 RMCD --> stage2 RMCD
User setup: TestUser {stage1 RMCD, stage2 RMCD}
I assumed giving editable access to the attribute def and attribute value where the name of the attribute was a user group (stage 1) and only that group had RMCD access to that attribute would enable this flexibility by controlling access to the object for these groups. Therefore, setting access to the object for the stage 1 group as R-only would mean that since only the stage 1 group had access to edit the stage 1 attribute this attribute would be locked from edit for this object only.
My test user is part of stage 1 and stage 2 as RMCD. Both stage 1 and stage 2 are RMCD for the module so each object inherits RMCD for both groups. However, when I reduce the access for either group, it has no impact to editability for either attribute. Thus, while the attribute is only editable by stage 1 and the object has stage 1 set for R-only the stage 1 attribute is still open for edit. It makes no sense.
It appears that since the user is part of a group that still has RMCD access to the object (stage 2) it completely over-rides and disregards the explicit settings of the attribute.
Any suggestions? Thanks -B MGDMGD - Wed Jun 10 20:01:06 EDT 2015 | |||||||||
Re: Object access disregards attribute access It is a little bit hard to understand the scenario you are outlining. Maybe simplifying the example scenario would help. Is this a DXL question? This is the DXL forum. There is another forum for DOORS questions. Anyway having said all that do you understand that if UserA is in GroupA and GroupB that UserA gets the sum of the permissions for GroupA and GroupB so restricting GroupB to Read only will not have any impact on UserA if he is also a member of GroupA and GroupA has edit access.
It appears that since the user is part of a group that still has RMCD access to the object (stage 2) it completely over-rides and disregards the explicit settings of the attribute.
That sounds like the expected behaviour. | |||||||||
Re: Object access disregards attribute access DOORS Access rights can be very complex. First you need to take into account group behaviour: - Access Records for a specific users override access record für groups which override access records for 'Everyone'. - If a user is inside multiple groups, than access records of all groups will be combined
Some actions require you to have multiple access rights. For editing an attribute you need: - Modify access on the module (otherwise you will not be able to go to edit mode) - Modify access on the object - Modify access on the attribute value As far as I understand in your case you only care about the attribute values. You could set them up as followed:
When a use is now in group G1 he can edit only Stage1, in G2 he can edit Stage2 and in both group both, in no group no attribute. For attributes this might work - for objects however you need to think if it can be practical to create groups for object access. You could now go and set specific access rights for users on object level. Then only users that are allowed on certain objects could edit attributes but only if they are in one of the groups G1 and G2 ... Still the major drawback of this approach is, that managing the access rights of a module like this is a real pain. Whenever something changes, an DB Admin must go in, run a script to reapply the access rights - especially with object access (which is inherited by default) you run into trouble with inheritance, when for example creating a new object. For these kinds of access schemes we used 'triggers' in the past, which prevented attribute modification under certain circumstances. With a pre-modify trigger you can "cancel" an attribute modification and effectively disallow access dynamically (e.g. depending on attribute values). While this is not completely secure (someone can prevent the trigger from loading) it is ok for enforcing a certain life cycle on object level. When it comes to access rights in DOORS I would keep it on module and attribute value level and I would try by all means to make them static (don't dynamically change the rights depending on a lifecycle state). Keep your attribute definitions and types locked since you want to maintain a homogenous data model. Hope that helps, regards, Mathias
| |||||||||
Re: Object access disregards attribute access Access for "attr def" access has nothing to do with whether users can change values. So lets only talk about "attr value" access. See the previous posts about combining group access. As with the others I'm not sure I understand your post completely. But I believe the fundamental issues you are missing is this:
This rule has some hidden nuances:
Try the following:
If you want detailed nuance control such as preventing attr-value changes for that attribute but only for "Requirements", you will need a well-written pre-attribute-save trigger.
You could "tell" the trigger the "Object is locked down" by providing some silly empty "Locked Down Objects" group "R" access to the Object (or could set a "locked-down" attribute flag); likewise provide this group "R" access to the Attribute. -Louie | |||||||||